Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000067_owner-urn-ietf _Fri Mar 28 02:52:45 1997.msg

Internet Message Format | 1997-04-01 | 12KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id CAA11236
    for urn-ietf-out; Fri, 28 Mar 1997 02:52:45 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id CAA11229
    for <[e-mail]>; Fri, 28 Mar 1997 02:52:40 -0500 (EST)
Received: from www44.inria.fr by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA14008  (mail destined for [e-mail]); Fri, 28 Mar 97 02:52:36 -0500
Received: by www44.inria.fr (8.8.5/8.6.12) id IAA19844; Fri, 28 Mar 1997 08:52:32 +0100 (MET)
To: [e-mail]
Path: usenet
From: Dan Connolly <[e-mail]>
Newsgroups: w3c.urn
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Date: Fri, 28 Mar 1997 01:52:21 -0600
Organization: World Wide Web Consortium
Lines: 337
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: beach.w3.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
To: Michael Mealling <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Dan Connolly <[e-mail]>
Errors-To: [e-mail]

Short version:
    (1) I suggest link types be integrated into this
    design and
    (2) as a result, I think that URLs and URNs can
    be used interchangeably
    (3) I think N2C needs another parameter to
    specify the schema of the URC.

Details:

Michael Mealling wrote:
> Abstract
>
> ... We might ask
> for a list of other identifiers that are aliases for the original URI, a
> bibliographic description of the resource the URI denotes, etc.

I suggest you word that more strongly; perhaps:

    Experience suggests that the following operations
    should be supported by the network infrastructure,
    in addition to retrieval:

        * requesting one or more URIs which
        are aliases of a given URI, or more generally:
        which URIs are linked to a given URI

        * requesting bibliographic or other
        descriptions of a resource (aka "metadata")

And cite reports on that experience. (altavista's link:
service, PICS labels, yahoo, Engelbart's backlink
requirement, etc.) Hmm... I see that
experience is cited in the intro. Good.

> Because of
> the diverse nature of resources on the network, it may be difficult (or
> impossible) to offer all those operations, therefore a means of indicating
> what services are and are not supported by a given resolver must be
> specified.

The argument is missing a premise: that an indication
of the available services is needed by the clients.
You make that point later (based on experience), but without
it here, the conclusion after the "therefore" doesn't follow.


> This memo gives an initial set of those operations, and the
> requirements that must be met when those operations are encoded in a
> protocol.

"intial set" gives me the willies. Do you mean to imply
that you'll specify the rest of the list some day? If so,
say so.

Are the names of these operations expected to be used
literally in extensible fields in protocols?
If so, is this namespace going to be managed in perpetuity?
By IANA?

My intuition says that we're after a fiarly small set
of primitives that doesn't need to be expanded: we don't
have to cover the needs of every application-level semantic;
just the distinctions that are critical in the name service.

> Also, in subsequent conversations it became obvious that, in
> most cases, some of the operations were inappropriate or difficult for
> certain identifiers. For example, ISSNs identify books or magazines that are
> serial in nature. An operation to return the resource for an ISSN pointing
> to "Time" magazine would result in dumping hundreds of thousands of pages of
> "Time" onto a user's machine. This does not seem like a reasonable thing to
> do in the normal case.

So... don't do that. :-)

Seriously: why do we have to give the machine any extra
information to prevent it from dereferencing the Time
magazine URI? Is there some scenario when the machine
might attempt to do this?

I think I'm missing something. Point me to the relavent
reading materials if you would, please.


> The Problem
>
> The problem, stated simply, was one of a client needing to convey to a
> service some idea of the desired operation on a URI that the client is
> currently talking about.

Hmm... I don't understand how normal protocol "opcodes"
or "verbs" or "methods" don't suffice for this. But I'll
keep reading...

> The problem was also that the server needed to
> convey to a client which network entity could perform which of the
> operations that were allowed for that particular URI.

This I agree with: some "preview" information is useful
to save round-trips in protocols.


> Any specification of a member of this set of operations MUST contain at
> least the following pieces of information with respect to its operands, its
> algorithm and its output.
>
>    * 2.1 Operands

Hmm... the URN WG needs its own interface definition language?

Hang on: the header of this document says it's intended
to be standards track, not informational. But this
is an abstact API design, not a wire protocol.
I didn't see that in the charter for this group.
Oh well...

While the number and types of the operands is good stuff,
I think some of the specification of the operations is
missing, especially the relationship between the operations.
For example: is N2L expected to be functional? is L2N
expected to be its inverse? (details below...)



> 4.1 N2L (URN to URL)
...
> This operation is used to map a single URN to a single URL.

In effect, it defines a relation
    N2L <: URN x URL
(where x means cross-product, and <: means subset)

This is where my point about typed links comes in: a
"link type" is exactly a two-place relations between URIs.

If an N2L operation on cid:23l4kj2lk234 yields ftp://...,
that has the same semantics as:

    <link rel="N2L" href="ftp://...">

when found inside cid:23l4kj2lk234 (assuming, in this
case, that it's an HTML document.)

So I would define the N2L operation as:
    Given a URI N, Return some URI L such that there is a
    link from N to L of type "N2L".

Note that N and L are both URIs. Hence my second point:
the distinction between URNs and URLs isn't necessary.


>  The algorithm
> for this mapping is dependent on the URN namespace.

What does that mean?

> 4.2 N2Ls (URN to URLs)
> This operation is used to map a single URN to 0 or more URLs.


This one becomes:
    Given a URI N, Return a set of URIs L[i] such that there
    is a link from N to L[i] of type "N2L" for each i.

Hmm.... Is this the same link type or not?

i.e. is the N2L relation a funciton? i.e. given a URI N,
is it OK if different services return different results
for N2L(N)? If N2L is expected to be a function, then
the N2L semantics are different:

    Given a URI N, Return *the* URI L such that there is a
    link from N to L of type "N2L".

If N2L is functional, then N2Ls needs a distinct link type
if it's to ever return more than one URI:

    Given a URI N, Return a set of URIs L[i] such that there
    is a link from N to L[i] of type "N2Ls" for each i.

> All URIs shall be encoded according to the URI specification [6].

I can't find reference 6. I'm terribly curious to know which
document you're citing for URI syntax.


> 4.3 N2R (URN to Resource)

> This operation is used to return a single instance of the resource that is
> named by the URN.

This is HTTP GET (and ftp RETR, and the analagous operation
in WAIS and ...). It has the same semantics, even if you use
a different mechanism. I suggest you use "GET" in place
of "N2R". But it doesn't matter too much.


> 4.4 N2Rs (URN to Resources)

An interesting twist on GET. Cool.

> 4.5 N2C (URN to URC)
...
> URCs (Uniform Resource Characteristics) are descriptions of other resources.
> This request allows the client to obtain a description of the resource
> identified by a URN, as opposed to the resource itself or simply the
> resources URLs.

FYI, the PICS spec gives an example of this operation:
    http://www.w3.org/pub/WWW/PICS/labels.html#Requesting

It has another parameter though: the metadata schema
that the URCs should conform to.

Hmm... I'll have to look closely at THTTP to see if
it's gratuitiously different from PICS.


> 4.6 N2Ns (URN to URNs)

> While URNs are supposed to identify one and only one resource, that does not
> mean that a resource may have one and only one URN. For example, consider a
> resource that has something like "current-weather-map" for one URN and
> "weather-map-for-datetime-x" for another URN. The N2Ns service request lets
> the client obtain lists of URNs that are believed equivalent at the time of
> the request.

Hang on: the relationship between current-weather-map
and weather-map-for-datetime-x isn't an equivalence relation.
Well... if it is, that's a misleading example.

The relationship you're talking about seems to be
the generic/specific relationship, which is VERY useful,
along with part/whole and a few others.

In terms of link types, I would describe this as:

    Given a URI N, return a set of URIs M[i] such
    that there is a link from N to M[i] of type
    "S2G" for each i.

where the S2G is specified to be transitive.

This seems distinct from the equivalence relationship:

    Given a URI N, return a set of URIs M[i] such
    that there is a link from N to M[i] of type
    "EQV" for each i.

> As the weathermap example shows, some of the equivalences will
> be transitory, so the the server should convey the length of time for which
> the mapping is valid.

That's the case for all metadata, no?

>  The result shall
> be encoded in a text/uri-list IMT.

s/shall/should/, no?


> 4.7 L2Ns (URL to URNs)

> This operation is used to discover the URN associated with a particular URL.

"the URN"? So this relationship is expected to be functional?
I think that's fine, as long as it's a conscious decision.

Something that I think should be specified: is L2N expected
to be the inverse of N2L?

> 4.8 L2Ls (URL to URLs)
> This operation is used to discover URLs that are considered equal to each
> other.

This one is clearly supposed to be an equivalence relation.
If N2N is also an equivalence relation, then I don't understand
the distiction.

As I suggested above, I think the essentail ones are:
    EQV : equivalence in any sense, as long as it's
        reflexive, symmetric, and transitive. This can be
        used for alias detection etc.
    G2S/S2G: generic-to-specific and the converse.
        transitive (and antisymmetric, I think).
    P2H/H2P: part-to-whole, whole-to-part. transitive
        and antisymmetric.
        This sort
        of metadata is repeatedly requested by
        search service providers who want to
        know when texi2html-chapter2 and
        texi2html-chapter3 are children of
        the same root.

Each of these is a special case of:
    Given a URI S and a URI T, return a set of URIs D[i]
    such that there's a link from S to D[i] of type T
    for each i.

These special cases are worth making exception,
(since full URLs for N2L and EQV would probably waste a lot of
bytes in DNS!) I suggest another operation for the general
case:

    S2D(URI S, URI T) -> set of URIs D[i]


> 4.9 L2C (URL to URC):
> This operation is used to retrieve the URC for a given URL

How is this distinct from N2C?

> 4.10 I2I (URI to URI):
> This operation is used to map any arbitrary URI to any other arbitrary URI.

Again, I don't see the reason for more than one equivalence
relation.

> 4.11 N2I (URI to URI):
> This operation is used to map a URN to any other arbitary URI.

And again.

> 4.11 I=I (Is URI equal to URI):
> This operation is used to determine whether two given URIs are considered to
> be equal by the server being asked the question.

And again.


Now... on to the specs that depend on this one.

--
Dan Connolly, W3C Architecture Domain Lead
<[e-mail]> [phone]
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21